IBIS Macromodel Task Group

Meeting date: 18 April 2017

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Broadcom (Avago):             Xingdong Dai
                            * Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
IBM                           Luis Armenta
                              Trevor Timpane
Intel:                      * Michael Mirmak
Keysight Technologies:        Fangyi Rao
                            * Radek Biernacki
                              Ming Yan
Maxim Integrated Products:    Hassan Rafat
Mentor, A Siemens Business:   John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
                              Kevin Li
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- None.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Dan: Second.
- Arpad: Anyone opposed? [none]

-------------
New Discussion:

BIRD 186.2 File Naming Rules:
- Walter: Currently IBIS limits file names to 40 characters.
  - As part of this BIRD we introduced relative paths to file name quantities.
  - Therefore, we wanted to increase that 40 character limit.
  - We considered various values and settled on 256 characters.
  - A colleague of mine recently reminded me that for the Windows OS 256
    characters is the hard limit on the total path (e.g. C:\....).
  - Therefore the 256 character limit in BIRD 186.2 is impractical.
    - The location of an IBIS library directory where an IBIS file lives might
      easily be 30 or more characters itself.
  - What should we reduce it to?
  - There are several solutions.  I'm leaning toward just reducing it to 64 or
    128 characters.  That way the EDA tool knows how long the path to its
    library directory could be before it risks running into an OS limit.
- Arpad: The original 40 character limit was for the file name itself (no path).
  - So 64 would seem too low a limit if the quantity includes a relative path.
- Radek: There are two cases:
  - 1. [File Name] keyword contains only the file name itself (no path).  For
       that one name, 64 would be more than enough.
  - 2. For quantities that include the path we might only be able to issue a
       caution for the user.  Even a short path used by the EDA tool to store
       a library might lead to an extremely long absolute path when everything
       is combined.
- Arpad: Are we talking about a limit on the file name itself or relative path?
- Walter: As the BIRD is written, it is the limit on the combined file name and
          relative path from the directory containing the IBIS file.
- Radek: In that case 128 is a reasonable limit, and we may still need a
         caution.
- Bob R.: We should use 128 as a limit, but explicitly state that the file name
          itself, as would appear in the [File Name] keyword, is limited to 64.
- Walter: Agreed.  I'll create a 186.3 draft 1 incorporating Bob's suggestions.
  - I'll email it to the group and we can review the text via email.

BIRD 166.1 Redriver Init() Flow Improvements:
- Walter: I came up with a slight change to my original proposal and sent it out
          recently. (see previous meeting minutes)
  - It precisely solves the redriver Init() flow problem by allowing the
    redriver Tx to see the right IR in case it needs to optimize itself.
  - The proposal now solves the redriver Init() flow problem with minimal text
    modifications to the spec.
  - Fangyi still objected based on the crosstalk issue.
    - I've recently sent him an email and am waiting for his response.
  - I think that's an independent issue.
  - I will submit this proposal to the Open Forum.  If there's good support
    there we can move forward.
- Arpad: I also forwarded your email to Vladimir.
  - Fangyi also raised a question about multiple (cascaded) redrivers.
- Walter: I think that was a non-issue.
  - The flow I'm proposing works fine.  You take every bit of upstream
    equalization and keep accumulating it.  That's all my BIRD says.
  - If Fangyi really objects, and I don't get support in the Open Forum, then we 
    may just reject BIRD 166.1.
- Arpad: So, the only issue is crosstalk?
- Walter: Yes, crosstalk was fundamentally wrong from the beginning.
  - To correct it you must have the model somehow return the part of the
    equalization that affects crosstalk.
  - The Tx model's Init() should return the Tx equalization, and the Rx model's
    Init() should return the Rx equalization in two parts (LTI part and the non-
    LTI part).
  - Fangyi is doing the right thing adding additional outputs to the Rx Init().
  - He should also add an additional output to the Tx Init().
  - That will solve the crosstalk issue, and it's independent of my BIRD 166.1.
- Arpad/Curtis: What about the issue you raised last week with DDR5 and the Tx
                optimizing the Rx?  Do we have a problem with the fact that we
                always call Tx AMI Init() first?
- Walter: BIRD 147 (back channel) could handle that.  The BCI protocol could
          call for the Tx Init() to write something to Rx Init(), even though
          BIRD 147 currently only allows the iterative calls in GetWave().  The
          protocol could allow the Tx to optimize the Rx during GetWave().  The
          protocol could even deal with the subtle issue that in BIRD 147 only
          the Rx can terminate the training.
- Bob R.: I have no problem updating BIRD 166 with this proposal, which is a
          simpler version anyway.
  - I still have concerns about whether agreement on technical content will hold
    up approval.
  - I still have concerns about whether a more advanced version would have any
    conflicts with this one.
- Walter: If I'm going to go through the extra effort of changing my proposal to
          deal with the additional information in the IR matrix, then I want to
          do it once and do it right.
  - What Fangyi is proposing is itself incomplete in that it doesn't handle the
    Tx that wants to optimize itself.
  - In the meantime we have a fundamental issue where the basic flow in the
    standard is incorrect.
  - We should fix that fundamental flaw so we don't have tools generating
    different answers because one follows the flow in the spec. and one does it
    the right way.
  - Crosstalk is a flaw at another level.
- Radek: The problem I see with BIRD 166.1 is that if we just go with it we may
         end up in a place where we can't get to the crosstalk solution.
  - BIRD 166.1 is no doubt an improvement over what's in the spec. now.
  - But it is something of a small hack at this point.
  - We may have to undo this approach to get to the final crosstalk solution.
- Walter: The input to the downstream Rx is the same in my flow as in Fangyi's.
  - Fangyi's flow adds two additional outputs to the Rx Init(), but they are not
    used for the main channel they're used for crosstalk.
  - To fully solve the crosstalk problem, you also need to get the IR of the Tx
    equalization.  That is what affects crosstalk from the upstream channel.
  - Since Fangyi's BIRD is independent, we should put all the effort into
    getting that one right all at once to solve the crosstalk problem.
- Radek: I see the improvement from BIRD 166.1.
  - But users don't want to hear that "we don't support that crosstalk case."
- Arpad: We have a flow problem, and we have a crosstalk problem.
  - Walter's BIRD 166.1 can fix the flow problem.
  - It doesn't fix crosstalk, but crosstalk is separate and the fix can be added
    later, right?
- Radek: The crosstalk fix may not be additive.
- Walter: If Keysight and others feel this way, then BIRD 166.1 will be tabled
          and won't get into the next release of the spec.  But we know tools
          should take note of the fact that the flow in IBIS 6.1 is wrong.

BIRD 158.4 - AMI Ts4file Analog Buffer Models:
- Walter: We deferred any vote in the Open Forum waiting for a recommendation
          from ATM.
- Bob R.: We would have to upload BIRD 158.4.
- Radek: We have the BIRD 158.4 draft 4 that I sent out right before the meeting
         two weeks ago.  We haven't had a chance to discuss it yet.
- Radek: [sharing the draft]
  - I got good feedback from Arpad, Bob R., and Bob M. and incorporated it.
  - I would like to get some from Ambrish since I added some phrases at his
    request.
  - But we could go ahead and make a recommendation without his feedback.
  - There are some changes to the schematics.
  - "buffer terminals" in the Tx and Rx schematics (from Arpad's suggestion).
  - "By definition, the placement of the Ts4file information within the .ami
     file makes the Ts4file data exclusively limited to AMI applications..."
     (paragraph added at Ambrish's request).
  - New Ts4file_Includes parameter (Bob Miller's suggestion)
    - Allows the model maker to tell the world what is included in the
      Touchstone file.
    - This can give the user the information on what the boundaries are for the
      "User Setup" block shown in the schematic.
  - We don't say anything about reusing legacy data.  We don't want to.  The
    point is that this BIRD bypasses the IBIS file entirely for the analog
    model.
- Editorial Corrections Noted:
  Bob Ross pointed out that all instances of <String literal> should have a
  lower case "s" in string.  Bob Miller pointed out that the allowed values for
  Ts4file_Includes are "buffer", "pad", and "pin" (not "package").  Radek agreed
  with these corrections and made the changes.
- Walter: I move that we make a recommendation to the Open Forum to approve
          BIRD 158.4.
- Bob M.: Second.
- Arpad: Anyone opposed? [none]


- Mike L.: Motion to adjourn.
- Curtis: Second. 
- Arpad: Thank you all for joining.

AR: Walter to send a BIRD 186.3 draft 1 to the ATM for review.
AR: Walter to send BIRD 166.1 to Mike L. to be posted as a BIRD on the
    Open Forum site.
AR: Radek to send BIRD 158.4 (with the editorial changes from the meeting) to
    Mike L. to be posted to the ATM archives as BIRD 158.4 draft 4 and to be
    posted to the Open Forum site as BIRD 158.4.

-------------
Next meeting: 25 April 2017 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
